home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1063 < prev    next >
Internet Message Format  |  1994-08-27  |  4KB
  1. From: Mark.Baker@mettav.exnet.com (Mark Baker)
  2. Date: 24 Jul 94  11:13:16
  3. Message-Id: <UUCP.775073468@mettav>
  4. Subject: Digest continued
  5. To: gem-list@world.std.com (gem-list@world.std.com)
  6. Precedence: bulk
  7.  
  8. Waldi:
  9.  > I didn't mean the specs for the source files which are compiled by HCP.
  10.  > I meant the specs for the format of the files read by the viewer (i.e.
  11.  > *.HYP, *.REF). If those formats are not documented they cannot become
  12.  > a standard. If they are documented, please let me know where to find
  13.  > these docs.
  14.  
  15. The specs for the .ref files are in reflink.hyp.
  16.  
  17. Guillaume:
  18.  > At this time I think that only english and german are supported under
  19.  > ST-guide. I won't release a commercial software with an online help system
  20.  > in english. We need to be able to translate every message of STguide in
  21.  > every language.
  22.  
  23. I am quite happy using the German version of ST-guide (english docs would have
  24. been useful though) However I would not want to distribute it with commercial
  25. software even though as a user I would be happy to get it.
  26.  
  27.  > This should be done for every software. On the falcon it's easy
  28.  > to detect the language of the TOS but on older machines ???
  29.  
  30. You need to look in the osheader IIRC. Not too difficult though. But a
  31. multilingual version would be much larger, I would prefer just different
  32. translated versions.
  33.  
  34.  > I also think that Stguide should be improved, when I see the help system on
  35.  > Windows.
  36.  
  37. It's not easy to write for. It does have some nice features though like support
  38. for different fonts and sizes. OTOH having different fonts like this means the
  39. user cannot choose a font as they can with ST-guide so if the one chosen by the
  40. author is too small, too large or too blocky to be usable on their system they
  41. are stuck with it
  42.  
  43. Chris:
  44.  > Go figure indeed.  C++ programs are larger than C programs because the
  45.  > _linkers_ being used were designed for C code.  Instead of being
  46.  > intelligent and linking in only the used members of a class (which is sort
  47.  > of what they do for C if your library is designed properly), it links in
  48.  > the whole class, which can be quite large.
  49.  
  50. No, it's the class programmers fault. If they put each method in a separate
  51. file instead of all in one module then it would not create such large
  52. executables.
  53.  
  54.  > I'll bet it won't make a GEM NetHack smaller than about 750k or so...
  55.  > (Not a fair test, since plain NetHack compiles to *at*least* 700-800k; I
  56.  > think Warwick had to leave out several features in the GEM NetHack on
  57.  > atari.archive... it's binary is over 800k if I remember correctly.)
  58.  
  59. Over a meg. AFAICS the only features left out are things like the demons that
  60. hand you a scroll when you recieve any email - since it predates MiNTnet there
  61. is little point.
  62.  
  63.  > Which is exactly what I'd call the Pure C optimiser...  GNU C's code may
  64.  > be large, but it's VERY good.  Personally, I have a hard drive, so I
  65.  > could care less if my binaries are a bit larger.
  66.  
  67. Yes, IME it optimises for speed very well but makes no attempt to cut down the
  68. size.
  69.  
  70.  > Uh-oh, now we'll get into the consistant-user-interface argument again...
  71.  > :)
  72.  
  73. Isn't that rather avant-garde, discussing something almost on topic? :)
  74.  
  75. Manfred:
  76.  >> they and where can I get one?
  77.  >
  78.  > Look at the end of these mail... ;-)
  79.  
  80. Please do not include large uuencoded files in a public mailing list.
  81.  
  82. David:
  83.  > Rick, if we get you ST-Guide's access method (when it's an ACC) could you
  84.  > make your ACC's interface fairly like it? I mean I've seen neither so
  85.  > I've no idea whether the fundimentals of each are different, but I
  86.  > wouldn't think so.
  87.  
  88. They both support the Pure-C protocol AIUI. However the format of the hypertext
  89. files is different.
  90.  
  91.  
  92.  
  93.